Skip to main content

Build a Drilling UI App

A drilling frontend app follows the selected rig and well in a Corva dashboard. Build against that supplied context first; fetch assets manually only when the workflow intentionally lets the user compare or select something outside the dashboard context.

What Corva supplies​

For the drilling segment, Corva UI maps the operational context as follows:

Context valueMeaningCommon use
rigThe selected drilling rigRig name, rig-level metadata, active operation
wellThe active or selected wellasset_id for dataset queries and well metadata
appSettingsSaved settings for this app instanceFilters, display options, customer choices
currentUserSigned-in Corva user, when availableUnits, company context, user-aware behavior

Access these values with useAppCommons from @corva/ui/effects.

1. Confirm the manifest segment​

Your generated manifest.json should contain:

{
  "application": {
    "type": "ui",
    "segments": ["drilling"],
    "ui": {
      "use_app_header_v3": true
    }
  }
}

Do not add completion to make the same package cover both workflows. The two segments receive different assets and usually require different UX.

2. Render the selected rig and well​

Replace the generated placeholder content while keeping the standard container and header:

import { AppContainer, AppHeader, EmptyState } from '@corva/ui/componentsV2';
import { useAppCommons } from '@corva/ui/effects';

export default function App() {
  const { appKey, rig, well } = useAppCommons();

  if (!well) {
    return (
      <AppContainer header={<AppHeader />} testId={appKey}>
        <EmptyState title="Select a well to view drilling data" />
      </AppContainer>
    );
  }

  return (
    <AppContainer header={<AppHeader />} testId={appKey}>
      <main>
        <h2>{well.name}</h2>
        <p>Rig: {rig?.name ?? 'No rig selected'}</p>
        <p>Asset ID: {well.asset_id}</p>
      </main>
    </AppContainer>
  );
}

AppHeader reads the same Corva UI context, so it can display the app title and current assets without receiving a copied set of app props.

3. Load drilling data for the well​

Most drilling datasets use the well's asset_id. A typical app flow is:

  1. Wait until well is available.
  2. Read well.asset_id.
  3. Query the required dataset with corvaDataAPI from @corva/ui/clients.
  4. Show loading, empty, error, and success states.
  5. Cancel or ignore outdated requests when the selected well changes.

Use the Data API reference to select the dataset and query parameters. Dev Center frontend apps should use the authenticated clients from @corva/ui; do not embed API keys or Bearer tokens in frontend source code.

4. Respond to asset changes​

The customer can switch wells without reloading the whole dashboard. Effects and cached queries that depend on operational data should include well.asset_id in their dependency or query key.

useEffect(() => {
  if (!well?.asset_id) return undefined;

  const controller = new AbortController();
  loadDrillingData(well.asset_id, controller.signal);

  return () => controller.abort();
}, [well?.asset_id]);

This prevents a response for the previous well from replacing data for the newly selected well.

5. Add settings only when customers need them​

Use AppSettings for persistent customer choices such as curve visibility, units, thresholds, or default ranges. Keep temporary UI state—open panels, hover state, and current tab state—inside the app unless it must survive reloads.

Continue with: